Overview

Move fork-child reaping and private-CWD deletion off the shared MCP proxy event loop while preserving the fork parent's single-threaded spawn boundary.

Why

A rollout close currently performs blocking waitpid(..., 0) and recursive rmtree(...) calls directly on the proxy loop. A metadata-heavy child directory can therefore pause heartbeats, timers, and requests to otherwise-ready rollout children for the full cleanup duration.

Design

• Keep child lookup, removal, waiter notification, and SIGKILL ownership on the proxy loop.
• Serialize cleanup with the existing fork lock so no replacement child can reuse a directory while it is being deleted and no fork() can run while a cleanup thread exists.
• Run ordered waitpid and rmtree work in one short-lived executor worker, then join that worker before releasing the fork lock.
• Let requests to already-ready children continue through the lock-free fast path.
• Finish the cleanup future before propagating cancellation, so a removed child cannot leave its private directory behind.

Performance and resources

A standalone PEP 723 benchmark reaped one real child and deleted an identical tree of 20,000 one-byte files across 21 directories. Three paired macOS/APFS runs produced these medians:

The optimization targets loop responsiveness rather than deletion throughput: the filesystem work remains the same, and wall time varies with metadata/cache behavior. The temporary worker is fully joined before another child may be forked. The workload opens no network connections, copies no bytes, and removes the same child process, files, directories, and payload in both modes.